Arrangement and a method relating to access of applications/services

ABSTRACT

The present invention relates to a portal structure for providing end user stations ( 5 ) with access to services/applications. It comprises a portal core ( 1 ) a connectivity layer via which end user station access is provided and a number of services/applications ( 25 ).  
     The services/applications ( 25 ) are represented in a generic markup language and the portal core ( 1 ) uses said generic markup language for storing at least application/service data information and for communication with said services/applications. It further comprises a presentation arrangement ( 11 ) for communication with said applications/services ( 25 ) and said end user stations ( 5 ). Each service/aaplication ( 25 ) represented by generic data in the generic markup language may optionally be provided with a number of metalink tags, such that each service/application ( 25 ) is able to generate generic link data in the generic markup language irrespectively of the location of the portal structure and of other applications. The portal core presentation arrangement ( 11 ) comprises first translating means ( 16 ) for replacing such metalinks with real (public) addresses of the services/applications ( 25 ), such that continuous navigation is enabled for end users irrespectively of the location of accessed services/applications ( 25 ).

TECHNICAL FIELD

The present invention relates to a portal structure for providing enduser stations with access to services/applications. Particularly itrelates to an Internet portal, and specifically it relates to a portalstructure providing an end user with improved navigation support. Mostparticularly it relates to a portal structure facilitating access toapplications/services irrespectively of the location of such servicesand irrespectively of which is the type of the end user station.

STATE OF THE ART

Continuous navigation in a portal relates to the ability to viewinformation and associations binding such information together. In somecases the information and the associated resources (application contentsand service contents) reside within the portal itself. However it isalso often the case that the information resides with third partycontent providers, which then themselves provide, and are responsiblefor, an infrastructure managing such information and for publishing ittowards the portal. In that case the portal must support the ability toconnect to external infrastructures and to provide appropriatenavigation facilities also to such services/applications not residingwithin the portal itself. By within the portal is meant that theservice/application/content providers are internal providers.

When referring to a portal is generally meant an Internet portal. Thereis also an increasing need to personalize or customize the way an enduser can access services irrespectively of the actual location of theservices or applications. At the same time the demand for access tomobile Internet services gains importance, i.e. the end users need to beable to, in a rapid and uncomplicated manner, get access to servicesfrom any end user station, i.e. also from mobile devices; it may e.g.relate to sending and a receiving e-mails, short messages and accessingweb-based information from mobile as well as fixed end user devices in auser friendly, quick and simple manner. This is called the mobileInternet.

Browsing using the mobile device is however more difficult than browsingusing a PC, since the mobile device, as compared to the PC, has limitedinput and output capabilities. This means that it gets even moredifficult to provide mobile end users with a satisfactorypersonalization and management of services. Generally there is anincreasing demand on behalf of the end users to always be able to accessapplications and services. A portal is such a doorway to the content ofservices and applications, which particularly should be tailored to suitthe end user preferences.

Examples of portal content are information services (also including pushcontent, which relates to an Internet technique through which allinformation a user subscribes to, or information that the serviceprovider or operator means that the user should be provided with,automatically is provided to the user). Examples on information servicesare weather forecasts, or weather information in general, commercialservices such as shopping malls, or generally any kind of information,multimedia services such as streaming audio/video, games, instantmessaging and newsgroups, web based mail, access to particularcommunities through chat-rooms. It is also highly desirable to be ableto provide appealing graphical user interfaces for representingapplications and menus on PC:s, and particularly also for WAP-enableddevices, in case a portal is mobile. Much effort is put down onpersonalizing the structure and the content of personal portals, and toprovide a possibility to control the interaction and behaviour ofindividual services and applications by setting personal preferences. Ithas however turned out to be difficult to provide for satisfactorynavigation properties as well as satisfactory access possibilitiesirrespectively of which kind of device that is used by an end user.

A portal core is here defined as the central part of the portalstructure that is needed to develop a portal framework within whichcontent and applications can be disclosed and accessed by end users in acontrolled and unified manner.

Until now many applications are in principle exclusively designed forthe 2G telecommunications environment and they have been implemented asmonolithical blocks or with a proprietary service network to handle thespecific QoS requirements for the respective applications. This has aconsequence that such applications work satisfactorily as isolatedapplications, but they are difficult to integrate with otherapplications developed in similar ways. Applications developed for theInternet (Internet protocol) environment have to a large extent beenbased on established and open de facto standards supporting extensiveintegration of different applications. Many such standards have beenused in the 2G environment for non real-time critical applications.However, through the introduction of 3G networks (3GPP), futureapplications will contain a mixture of telecommunication anddatacommunication services, mixing higher and lower bit rates, as wellas real time and non-real time traffic. The service networks of todayare not designed to handle such mixtures and the existing IP-basedapplications are also not designed for the specific characteristicsassociated with wireless networks. As can be seen there are many factorscomplicating the provision of satisfactory access for end users toservices and there are no straightforward solutions and satisfactorysolutions to the problems associated with the provision of seamlessnavigation in a portal for end users.

WO 00/49519 discloses a solution with a storage scheme where conversionsare applied to content, the content being unaware of the specificconversions applied. However, the storage scheme is static. Hence thetransformation to be applied to the specific content is fixed (not useror device specific). It is not possible to dynamically decide on the(set of) conversions to be applied on specific content. In order to beable to serve a plurality of heterogeneous client devices would requirea huge directory structure and a proliferation of redundant contentcopies, each copy in a different directory. Thus, the described solutionsuffer from apparent disadvantages and drawbacks.

SUMMARY OF THE INVENTION

By using a generic markup language in a portal, content of applicationsand services can be stored independently of end user station or userdevice, and before showing the content of an application or a service,the content can be transformed into the format, i.e. the markuplanguage, that can be understood by the end user device. One example ofsuch a generic markup language is the XML (Extended Markup Language). Asa standard for navigation in an XML-based portal is the XLinkspecification used, which allows elements to be inserted into XMLdocuments in order to create and describe links between resources. XLinkprovides a framework for creating both basic unidirectional links andmore complex linking structures. It allows XML documents to assertlinking relationships among more than two resources, associate metadatawith a link and to express links residing in a location separate fromthe linked resources. However, continuous navigation between portals andparticularly external content providers can not be achieved throughsimply using XML and XLink.

What is needed is therefore generally a portal structure providing anend user with fast and easy access to services and applicationsirrespectively of whether the services and applications (content) arelocated within the portal structure itself or whether theapplications/services and the content thereof reside outside the portal(i.e. are provided by external providers). Particularly a portalstructure is needed which is capable of providing an end user with quickand simple access to content of applications and services, also if thewanted services/applications require special access rights, or moregenerally a portal structure supporting handling of dynamic issues, likeaccess control etc.

A portal structure is also needed through which service/applicationproviders are able to provide the same navigation features in thecontent they supply as the portal structure itself does, i.e. as it doesfor applications/services residing within the portal. A portal structureis also needed which is able to provide a common “look and feel”irrespectively of where applications/services reside or by whom they areprovided. Particularly a portal structure is also needed which iscapable of storing content independently of user access device or userstation, and supporting transformation of content of applications andservices to the format of the user device or a format that the userdevice (i.e. the end user station) is able to understand. Even moreparticularly a portal structure is needed through which the number ofparameters that have to be sent to applications/services (contentproviders) from the browser of an end user is reduced as compared tohitherto known structures.

Particularly a portal structure is needed which allows for connection ofa large number of internal as well as external service and applicationproviders, or content providers, while still providing the samenavigation features to external providers as to internal providerswithout requiring an extension or additional programming of the portalimplementation. Even more particularly a portal structure is neededwhich is mobile, i.e. which allows access by mobile end user stations,and specifically a portal structure is needed which allows mobilestation as well as fixed station access. Still further a portalstructure is needed which is end user friendly and easy to use and whichallows user personalization or customization such as to suit thespecific needs and preferences of different end users. Particularly aportal structure is needed which in an attractive way integratesInternet and WAP (Wireless Application Protocol) based services so thataccess is enabled from any Internet connected PC, WAP-device or anyother mobile device using various mobile access networks such as forexample GSM (Global System for Mobile communications), GPRS (GSM GeneralPacket Radio Service), WCDMA (Wideband Code Division Multiple Access),UMTS (Universal Mobile Telecommunications), SMS (Short Message Service),broadband also allowing access by PDAs (Personal Digital Assistant),i.e. technology independent access.

In the following some further concepts used herein will be described ordefined. A portal is generally a non-physical entity in the Internetdomain, which can be described as an “electronic publishing space” whichis owned by an individual or an organization, and which provides eitherdirect access to information and services, or links to other entities inthe Internet or private intranet domains, providing information andservices to authorized end users. A portal is in its simplest form aregular home page or list of links, whereas in more advanced forms itmay offer interactive services not only to those who consume what ispublished, but also to those who are granted the right by the editor topublish on the portal, as well as to the editor himself, regardingdifferent aspects on how the portal is used.

Wireless end users are given access through a “service” portal. Such a“service” portal is different from a traditional fixed Internet portalfor PCs and end users demand personalized services delivered to andpresented on their mobile terminal at least as an option. In thisdocument the concept portal (structure) is used. It can be both aconventional Internet portal or a “service” portal, a mobile portal.

An application is one or several cooperating software entities, thefunctional focus being user interaction and usefulness for the end user.An application platform is a defined combination of software andhardware entities used to implement applications of a certain kind,which are characterized by the functionality and quality of itsconstituent parts.

By portal infrastructure is, in general terms, meant the software andhardware entities needed to either host or produce or generate aspecific portal. Specifically it contains a portal core, an IPinfrastructure and service enabling means.

A service enabling means, here also denoted a service enabler, is asupport functionality accessed via APIs (Application ProgrammingInterface) raising the abstraction level and simplifying the applicationdevelopers task. The portal core, as referred to above, is the core of aportal infrastructure. By a service network is generally meant anIP-based network which consists of nodes hosting application servers,service capability servers, application support servers, IPinfrastructure servers etc. Application support servers interface withservice network resources or other external resources than corenetworks, whereas service capability servers interface with resourcesand functionality in core networks. In the present application a portalstructure is intended to mean a portal core, a plurality of services andapplications with their content and service enabling means (serviceenablers). Generally may also the connectivity and data bearerfunctionality be seen as included.

Therefore, in order to solve one or more of the problems referred toearlier in the document, the invention discloses a portal structure, forproviding end user stations with access to services/applications, i.e.the content of services and/or applications. It comprises a portal core,a number of service enabling means, connectivity means acting as databearer and via which end user station access is provided, andservices/applications (providers). The services/applications use orgenerate a generic markup language to represent a content, the portalcore uses said generic markup language for storing application/servicedata information and for communication with said services/applications.The portal core also comprises a presentation arrangement forcommunication with the applications/services and with said end userstations. Each service/application as represented by generic data in thegeneric markup language may be provided with one or more metalink tagsreferring to other services, applications or content (internal orexternal) such that each service/application is able to generate genericlink data by means of the generic markup language irrespectively of thelocation of the portal core and of other applications/services. Theportal core presentation arrangement comprises first translating meansfor replacing such metalinks with real (public addresses) of theservices/applications content referred to, such that continuousnavigation is enabled for end users irrespectively of the location ofservices/applications (content).

The portal core presentation arrangement particularly comprisesrendering means which includes said first translating means.Alternatively the rendering means are provided separately in the portalcore and only comprises second translating means for translating(rendering) service/application data presented in the generic markuplanguage into a format, or a markup language, as understood or used bythe end user station having requested a service or an application.

A portal core further comprises session handling means for user sessionmanagement. Particularly service logic is kept separate frompresentation related logic. Said session handling means are alsoseparate from the rendering means.

According to the invention a number of different types of metalinks canbe defined such that an application or a service can be provided withthe appropriate kind(s) of metalink(s) depending on where the content tobe referred to resides. In one embodiment four different kinds ofmetalinks are defined, although the inventive concept of course not islimited to the definition of four different kinds of metalinks or to thespecifically exemplified metalink types. However, according to oneembodiment the first metalink, which may be denoted a metalink of type“self” is defined which refers to the service/application that itselfhas generated the data as represented by the generic markup language. Asecond metalink type “local” may also be defined which refers toresources which are local to the service/application. It includesinformation about the path to the resource in relation to theservice/application. A third metalink type “absolute” is defined whichcomprises a link to any public or private portal, WEB-page, resource,application or content and it contains a reference with the complete URL(Uniform Resource Locator) to such resource, content etc. Finally afourth metalink type denoted “application” is defined, according to thisembodiment, which refers to an application defined in the portalstructure under a given name and it contains information about saidname.

Particularly data representing services/applications as expressed in thegeneric markup language and metalinks are defined in a Document TypeDefinition (DTD) language with an URL-attribute. DTD is e.g. an XMLdocument describing all the elements and their attributes which areallowed in all the documents belonging to the particular DTD.

In a most advantageous embodiment the portal structure is mobile, i.e.it supports access by mobile end user stations over a mobilecommunication network such as for example GSM (Global System for Mobilecommunications), GPRS (GSM General Packet Radio Service), UMTS(Universal Mobile Telecommunications System), Bluetooth (which is ashort range radio technology), WAP (Wireless Application Protocol) etc.Advantageously the portal structure supports access by broadband devicessuch as PCs or more generally fixed devices as well as mobile devicessuch as WAP-devices.

In other terms the portal structure supports access by fixed as well asmobile end users stations using different access formats or usingdifferent markup languages for communication with the portal structure.Detection of the type of a requesting end user station may be done inany appropriate manner. However, it may with advantage be performed asdisclosed in the copending Swedish patent application “An Arrangementand a Method Relating to End User Station Access of a Portal” which wasfiled on the same date as the present application, by the sameapplicant, and the content of which herewith is incorporated herein byreference. In that application it is disclosed how an end user stationcan get access to the portal structure itself, also if the type of theend user station is not known to the portal structure, as long as theclass to which the type belongs is known to the portal, which adaptivelywill get to know new types, i.e. it is generally adaptive to new types.

According to one particular embodiment a service or an application mayoptionally be provided with one or more metainformation tags. Therendering means adds the parameters of such a metainformation tag to allmetalink parameters at least for some types of metalinks. Particularlythe metainformation tags can optionally be added to “self” or“application” type referring metalinks and all parameters common to allthe links of an application are stored in the portal core per end userand per application instance. All parameters common to all the links inthe application will then be defined in one place and can be stored bythe portal. The stored parameters can then be sent to the applicationwhen the end user accesses the application next time (in the samesession). The parameters will, as referred to above, be stored per enduser and per application instance which means that different applicationinstances can have different global parameters. The advantage thereof isthat the addresses (URLs), of applications that need to be sent to theend user, get much shorter. This is particularly attractive in case theend user accesses the portal using a mobile end user station, i.e. aWAP-device. Only parameters that differ in different links will have tobe sent to the end user station, i.e. when different links within oneand the same application or service have different parameters.

It is also possible to add such metainformation tags to other links thanmetalinks, e.g. XLinks. The functioning will be the same as thatdescribed above referring to metalinks. Thus, addition ofmetainformation tags to some kind of links is generally advantageousalso in case the concept of metalinks is not implemented, e.g. sinceshorter URLs can be used to e.g. a mobile end user station.

Although the invention is not limited thereto, in a particularlyadvantageous implementation, the generic markup language used by orgenerated by the services/applications and the portal core, particularlythe presentation arrangement of the portal core, is XML. The XML-dataand the metalinks are defined in a Document Type Definition language(DTD) and a metalink tag in XML-data comprises information aboutmetalink type, a reference and addressing attribute (URL) containingservice/application location information. The second translating means(of the rendering means) translates XML-data by performing atransformation (XSL), i.e. the XML-data is processed with atransformation stylesheet (XSL transformation) to produce an outputformat, i.e. a markup language, appropriate for the accessing end userstation, e.g. HTML for a fixed end user station and WML for a mobile enduser station.

XML is e.g. described in Extensible Markup Language (XML) 1.0 (Secondedition), W3C Recommendation 6 Oct. 2000. XSL/XSLT is described in XSLTransformations (XSLT) Version 1.0 W3C Recommendation of 16 Nov. 1999and XSL Transformations (XSLT) Vers. 1.1., W3C Working draft, 12 Dec.2000. These documents are herewith incorporated herein by reference.

A portal structure is particularly disclosed which provides end userstations with access to applications/services. The portal structurecomprises a portal core, a number of service enabling means, aconnectivity and data bearer layer via which end user access is providedand a number of services/applications (providers). The portal core istypically XML-based and uses XML as a markup language for storing dataas XML-data and for communication with services/applications. The portalcore further comprises means for presentation on end user stations. Theservices/applications are represented by XML-data in the portal core andeach service/application in XML-data may be provided with/generate oneor more metalink tag(s) such that each service/application is able togenerate XML link data independently of which is the location of theportal core and of the services/applications. The portal core furthercomprises first translating means for replacing metalinks with realaddresses of the services/applications (content) referred to. The portalstructure is, according to an advantageous implementation, mobile andsupports end user access by mobile as well as fixed end user stations,e.g. WAP-devices and broadband devices such as PC:s, (or rather the usedbrowser) interactive TV etc.

A portal structure for providing end user access toservices/applications is provided which comprises a functionalservices/applications layer, a user access layer and an intermediatecommunication layer for communication with services/applications andwith the end user via the access layer. The intermediate communicationlayer comprises a presentation arrangement with rendering means andsession handling means receiving requests for services/applications byend user stations, forwarding said requests for services/applications byend user stations to the service/application layer, receiving XML-datainformation representative of the requested services/applications, andcomprising means for converting such XML-data information representativeof requested services/applications to a format usable by the requestingend user station. The services/applications may be provided withmetalink tag(s) and said presentation arrangement comprises translatingmeans for replacing metalinks with corresponding real addressinformation of the service(s)/application(s) referred to by themetalink(s). Instead of XML any other generic markup language withsimilar properties may be used.

The invention also discloses a method for providing end user stationswith access to services/applications via a portal structure comprising aportal core, services/applications and end user connectivity means,which method particularly includes the steps of; receiving in the portalcore a request for a service/application from an end user station in anend user station markup language; forwarding the request to therequested service/application; receiving data relating to the requestedservice/application as represented by a generic markup language whichmay include one or more metalink tags referring to (other)applications/services/content in the portal core from theservice/application; translating the metalink tag(s) to real addressesof the application(s)/service(s) referred to in the portal core;providing the data of a requested service/application to the end userstation in a format (markup language) appropriate for the end userstation.

The portal core particularly comprises rendering means which perform thesteps of; detecting if data of a service/application in the genericmarkup language contains one or more metalinks; if yes, processing saidmetalink(s) and replacing it/them with (a) real address(es) of theservice(s)/application(s) referred to. Particularly the method includesthe steps of; providing a service/application with a metalink of a giventype depending on where the requested content of a service/applicationreferring to is located.

The method may comprise the steps of; providing an application/servicewith a metalink tag referring to the application itself if the contentof the application/service referring to is provided by theapplication/service itself; providing a service/application with ametalink tag referring to local content if the content referring to isprovided local to the service/application, which metalink contains areference to the path to the content in relation to theservice/application; providing a service/application with a metalink tagreferring to a link to any portal, content etc. which comprises anattribute with a complete URL address of said portal, content etc.and/or providing a service/application with a metalink referring toanother service/application if the content to be referred to isassociated with an application/service known and given a name in theportal structure, including a reference attribute containing the givenname.

The method with advantage includes the steps of; providing aservice/application with a number of metainformation tags comprising anumber of parameters; adding the metainformation parameters to themetalink parameters; storing the metalink parameters and themetainformation parameters which are common to all the links of theservice/application in common in storing means of the portal core peruser and per service/application instance; sending the parameters thatare different for different links to the requesting end user station.The method preferably includes the steps of; translating theservice/application data expressed in the generic markup language intothe markup language used by the requesting terminal station. Stillfurther, particularly the portal structure is mobile and supports accessby mobile end user stations, e.g. WAP-devices, as well as fixed end userstations, e.g. PC:s. In a particular implementation the generic markuplanguage is XML and the rendering means supports translation into e.g.HTML (HyperText Markup Language) as well as WML (Wireless MarkupLanguage).

The invention also discloses a method of accessing a service/applicationfrom an end user station comprising the steps of; accessing a portalstructure by selecting a link with parameters to a desiredservice/application; performing a look-up to find the real address ofthe service/application in the portal structure; adding the linkparameters to the real address; examining if any metainformationparameters are stored relating to the requested service/applicationinstance for the requesting end user; if yes, adding the storedmetainformation parameters to the real address with added linkparameters; sending the request containing at least link parameters tothe service/application; delivering application/service data expressedin a generic markup language (XML) and including possible metalinks andmetainformation to the portal core; replacing metalink addressinformation by real address information; storing any receivedmetainformation in storing means associated with the portal core;processing the service/application data in a generic markup language byconverting it into the/a format (markup language) used by the end userstation.

It is here supposed that applications/services, irrespectively of wherethey can be found, are expressed as e.g. XML-data, optionally includingmetalink tags and/or metainformation tags.

The present invention discloses a dynamic conversation selection (basedon arbitrary/complex criteria) and it shows a system/method that canhandle a plurality of heterogeneous client devices. The inventiveconcept also allows easy extension for new devices or device types.However, according to the invention the source of specific content(application/service/provider) is determined dynamically, and thus notknown to neither users nor content providers themselves. Further,content providers can address own/other content without need to know:Source, means service/applications-specifics. Location and configurationof portal infrastructure especially if content is located inside oroutside portal provider infrastructure. In addition, client accessescontent without knowledge of physical storage locations.

Still further it provides for device-specific content requestadaptation, content request and reply adaptation according to devicecapabilities, implied security feature, since sensitive parameters arenot disclosed to user, while still sent in actual content requesttowards application/service and particularly user-specific/personalizedcontent presentation. According to the invention locations are notexposed, and hence they can be changed during normal operation.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will in the following be further described in anon-limiting manner and with reference to the accompanying drawings inwhich:

FIG. 1 schematically illustrates an overview of a portal structureaccording to the invention,

FIG. 2 illustrates the portal structure of FIG. 1 somewhat more indetail,

FIG. 3 very schematically illustrates the procedure when a mobile and afixed end user station access an application via the portal core,

FIG. 4 illustrates a conceptual division of the presentation arrangement(layer) into a rendering functional layer and a service functionallayer,

FIG. 5 illustrates in a simplified manner provision of application datato a mobile end user station through a portal core,

FIG. 6 is a flow diagram illustrating the procedure when an end userstation accesses an application according to a first embodiment,

FIG. 7 is a somewhat more detailed flow diagram illustrating end useraccess to an application, and

FIG. 8 is a further flow diagram illustrating access to an applicationin an embodiment in which the application is provided withmetainformation tags.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 shows one example on a portal structure 10 according to theinvention. The portal structure 10 comprises a portal core 1 handlingpresentation functionalities, subscription and session managementfunctionalities, a number of services and applications 2, comprising forexample personal communication services, personal information servicesand Mobile E-Commerce services. In FIG. 1 some examples on services andapplications are given such as mobile mail, navigation services, hotelguide information, mobile shopping etc. In brief it is not importantwhich kind of services that are provided and the inventive concept isapplicable to any kind of service, content and application. Whenexplaining the inventive concept in a more detailed manner, when an enduser requests access to a service or an application, any service orapplication (or content) is meant and can be seen as conceptuallyincluded in the portal structure although some of the services andapplications actually are located outside the portal structure and areprovided by any external service provider.

The portal core structure 1 further includes a layer 3 including anumber of service enabling means or service enablers 31-37, 38A-38D. Theservice enablers are among other things involved in authentication andbasic services such as gateways and IP infrastructure. In this figuresome examples on service enablers are given such as unified messaging31, IP infrastructure 32, AAA-Server 33 (to be further explained withreference to FIG. 2), notification support 34, charging support 35 andoperation and maintenance support 36. Further service enablers aremobile positioning system 37, WAP gateway 38A, SMS-C gateway 38B,multimedia proxy 38C, mobile E-pay 38D etc. It should be clear that someof these service enablers are more or less mandatory whereas others areoptional. This will be further discussed with reference to FIG. 2.

The portal structure is here also seen as including a connectivity or a(mobile) bearer layer comprising the mobile base stations and switchingnodes, such as BTS (Base Transceiver Station), BSC (Base StationController), MSC (Mobile Switching Center) nodes etc. Which the nodesare, depends on which mobile network access is provided over, e.g. GSM.For GPRS or UMTS corresponding nodes are included in this layer; forexample GGSN (Gateway GPRS Support Node). Whichever is the network, thenetwork is the data bearer for the portal for access of mobile devicessuch as WAP-devices (Wireless Application Protocol). In

FIG. 1 it is supposed that the accessing end user station comprises aWAP-telephone 5.

One example on such a portal structure is the Ericsson WISE™ Portal.

In FIG. 2 the portal structure is illustrated somewhat more in detail,particularly as far as the portal core is concerned. The services andapplications mobile mail 21, hotel guide 22, navigation 23 and mobileshopping 24 are the same as in FIG. 1. Internal applications or servicescan be seen as applications leveraging the service enablers andconnectivity layers to add application specific values to mobileInternet applications of various categories, for example mobileservices, personal communications as unified messaging or mail servicesand personal information services. The information may be retrieved bythe user through searches, but the information may also be provided tothe end user by means of the push technology. This is open to end usercustomization.

It is here supposed that the portal supports access by mobile end userstations, such as WAP-telephones 5 over a mobile network as discussedwith reference to FIG. 1. Therefore nodes or components of the relevantmobile network have to be provided in the mobile network connectivityand data bearer layer. In this embodiment a component denoted ISPnetwork, Internet Service Provider network is disclosed. This is anoptional component which may be included or not.

In the layer comprising the service enablers 3 some types of serviceenablers are mandatory whereas other are not. Some of the serviceenablers are important components for providing mobile Internetfunctionalities. Some of the service enablers are seen as one part ofthe interface components between Internet and the mobile network. Onecomponent is here denoted IP infrastructure 32. An optional serviceenabler comprises the notification support 34 which generally is anoptional component enabling applications to send out filterednotifications to end users using the SMS (Short Message Service)channel, but it may also be adapted to include other channels supportingWAP technology and 3G (3GPP) technology. Charging support enabler 35 maybe provided to allow for flexibly choosing charging events. Anotherservice enabler 36 relates to operation and maintenance support andgenerally it is a mandatory component. A service enabler WAP gateway 38Arelates to an optional service enabler WAP gateway/proxy forming theaccess point between the wireless world and the Internet world. Itsupports mobile clients accessing the WAP gateway/proxy using GSMcircuit switched data or WAP over SMS (SMS over MAP (Mobile ApplicationProtocol)). The client uses a WAP enabled browser in the mobile deviceto connect to the WEB-server where the desired WAP application resides.Another service enabler, mobile positioning system, 37 is an optionalcomponent allowing sending the position of a user to the applicationrequesting it. Another service enabler is here a multimedia proxy 38Cresponsible for transmitting multimedia data over GPRS or UMTS. Thishowever is an optional service enabling means. Also SMS-C (center) 38Bis an optional component responsible for sending or receiving, storingand forwarding short messages between mobile stations and servers.Proprietary protocols are used for communication with applications.Mobile E-pay 38D is a component offering the basic functionality forMobile E-Commerce and it is an optional component. Finally, cf. FIG. 1,AAA-Server is a service enabling component relating to authentication,authorization and accounting. These functionalities may be provided inother manners but they may also be integrated in a functionality serverfor example enabling traffic based charging and period charging. Such acomponent, either if it is split up into different components orcomprises one component which is common for a number of functionalities,is mandatory.

However, it should be clear that FIG. 1, FIG. 2 merely show examples onservice enabling means that may be provided in a service enabling layer3. At least some of the illustrated service enablers may be excluded,others may be included etc.

The portal core, or the portal core layer, handles, as referred toabove, presentation, subscription and session management and servicetiers comprising a number of internal (and external) applicationservers. The core 1 comprises a presentation arrangement 11 whichenables mobile portal presentation on multiple devices using multipleprotocols. It may e.g. be XML driven (or more generally driven by ageneric markup language). In one implementation it is a Java™ and XMLdriven multimarkup language capable presentation module.

The presentation arrangement 11 comprises a rendering means or arendering engine which in one implementation uses XML/XSLT technologiesto ensure that information presented by services within the portal isdisplayed in a standardized way regardless of which end user station anend user uses when accessing the portal structure. Through the use of ageneric markup language, for example XML/XSLT, the portal is able tooffer a unified “look and feel” of content presented within the portalpresentation space, i.e. it ensures that the use of for example colors,fronts and background images are enforced for all services displayingtheir information through the portal. The patent application titled “AnArrangement and a Method for Presentation Customization in a PortalStructure”, which is a patent application filed on the same date and bythe same applicant as the present application, and the content of whichherewith is incorporated herein by reference, relates to usercustomization in a portal structure as described herein, andparticularly it is concerned with presentation issues, “look and feel”.Such a functionality may, in an advantageous implementation, be includedin the portal structure as claimed in the present invention.

The functionalities within the portal core 1 and of the presentationarrangement 11 in particular will be further described with reference toFIGS. 3 and 4 and 5.

The portal core 1 also includes the subscription manager 12. In oneimplementation subscription manager component information is stored inan LDAP (Lightweight Directory Access Protocol) directory and it ismanaged by the service called subscription manager. The subscriptionmanager includes functions for the operator to create, maintain anddelete subscriber information in the subscriber database. It alsoenables the end user of the system to register with the services in thesystem. In a particular implementation a self-registration andself-service concept is supported in order to minimize costs byminimizing the workload on a customer care center. Information aboutavailable services may also be kept in the directory referred to aboveand handled by the subscription manager. As a new service is enteredinto the directory, it will immediately be available for subscription bythe end users. In the directory end users can be grouped so as to makenew services available only to defined sets of end users. Thesubscription manager 12 can be interfaced with an existing customer caresystem through the Application Programming Interface (API) it uses.

The session manager 13 is a general mechanism that can be used byapplications and services. It comprises an interface to a subsystem forkeeping track of all visitors to the portal and to provide the profileinformation of the visitors. When an end user enters thesystem/application a session-id entity is allocated and it is stored forthat particular end user until logging out of the service or when theend user has been idle for a preset period of time. When a participatingapplication starts, it first checks if there is an active session-id fora particular user and if there is, it would be able to resume from wherethe session was broken. The Swedish patent application “An Arrangementand a Method Relating to Session Management in a Portal Structure”,which is filed on the same date and by the same applicant as the presentpatent application is herewith incorporated herein by reference. Itdiscloses an advantageous way of unifying session management of portalsessions and sessions of external (externally session managed)services/applications. This concept may also be implemented on a portalstructure as disclosed in this document.

Finally the portal core structure 1 here comprises two “internal”application servers 14A, 14B and one or more external application server14C. The external application server 14C contains links to externalapplication servers running existing services. In one implementation theservice tier comprises three classes of services, of which a first isdeveloped in compliance with the portal core specifications implementedusing the portal core environment. The second service class relates toservices which not necessarily are implemented in the portal coreenvironment, such as for example an external e-mail system running on anon-portal core environment adapted to present itself through the portalcore presentation. The third service class relates to external serviceswhich do not comply with the portal core service development orpresentation architectures. This will be further explained withreference to FIG. 4. FIGS. 1 and 2 above describe one example of aportal core structure in which the inventive concept can be implemented.

The inventive concept will now be further described, first withreference to FIG. 3, which shows an implementation in which it issupposed that the portal structure supports access by mobile as well asfixed end user stations.

FIG. 3 shows for example the portal core structure 10 of FIG. 1 or 2 butonly including the components of main interest for the functioning ofthe present invention. In the figure it is illustrated how a fixed enduser station 6 via WEB-browser sends a request 1 _(RF) to thepresentation arrangement 11 of the portal core 1 for an application. Thefigure also illustrates how mobile end user station WAP 5 sends arequest 1 _(RM) to the presentation arrangement 11. In both cases thepresentation arrangement 11 of the portal core 1 forwards the request 2_(RFM) to the application 25 e.g. using HTTP (Hypertext TransferProtocol). As an alternative to HTTP may any other appropriate protocolbe used, e.g. RMI (Remote Method Invocation). The application may be anapplication which is provided within the portal core but it may also bean external application. Although the application is illustrated in thisfigure as residing within the portal core structure, the functioningwould be the same if it was provided externally and application 25 isthus conceptionally an application which is either internal or externalto the portal core structure. It is however presupposed that theapplication uses or generates a generic markup language, in thisembodiment XML. Of course some other generic markup language withproperties similar to those of XML may be used, although in thefollowing it will be referred to the XML language, since this relates toa particularly advantageous implementation.

According to the invention one or more metalink tags may be introducedto the application XML data for providing references to otherapplications, services, content within or outside the applicationitself. The applications can then produce XML link data independently ofthe location of the portal or of any other services/applications. Theapplications do not need to know their own or other applications public(real) addresses. The application 25 then returns XML data 3 _(XML),which may include one or more metalink tags, to the presentationarrangement 11. The presentation arrangement includes a rendering means(not shown in this Fig.) with first translating means for translatingthe received metalink(s) (if there are any included in the XML data)into real public addresses for the application(s)/service(s)/content asindicated by the metalink(s). Thus, the translation of the metalinksinto real public addresses for the applications will be done in theportal core instead of by the applications themselves. Thus, when, orif, application 25 in this case, delivers XML data containing metalinks,the rendering process within the rendering means, i.e. the firsttranslating means of the rendering means, will filter out the metalinksand replace them with the correct addresses to the respectiveapplications, services etc. The metalinks may be defined, as all XMLdata, in a Document Type Definition language (DTD) as e.g.: <!ELEMENTmetalink (param*)> <!ATTLIST metalink type  (self | local | absolute |application ) #REQUIRED ref CDATA #MPLIED url CDATA #MPLIED> <!ELEMENTparam EMPTY> <!ATTLIST param name CDATA #REQUIRED value CDATA #REQUIRED>A typical metalink tag in the XML data will look like: <metalink type=“self”> <param name=“cmd” value=“hello” /> </metalink>

When the first translating means of the rendering process/means detectsthe above metalink tag, it will look up the address for the currentapplication and insert the real address in the “url” attribute. Theparameters in the “param” tags may also be added to the address. The urlattribute can be used by the application generating the metalink, but itwill be overwritten by the rendering process. This makes it easy to testthe applications and the generated XML data without needing to processthe XML data through the portal structure. The application can in theurl attribute put a temporary url to itself for testing, but when theapplication is tested through the portal, it will work without changingthe code.

After the metalinks have been processed and translated by the firsttranslating means (not shown in this Fig.), the subsequent step of therendering process will take place in the second translating means usedto process the XML data with a Transformation Stylesheet (XSLtransformation), to produce an output appropriate for the end userterminal 5,6, i.e. for end user terminal 5 which is mobile the response4 _(WML) will be provided in the WML (Wireless Markup Language) whereasto the fixed end user station 6 the response _(4HTML) will be expressedin HTML (Hyper Text Markup Language).

The transformation will thus recognize the metalinks and extract the urlattribute and format, i.e. in the markup language as it is expected bythe respective end user stations. Continuous navigation within theportal is then enabled and the associations between available contentcan be stored in a device (end user station) independent formatirrespectively of whether the content that it accessed, i.e. the serviceof the application, resides within the portal or is externally provided.Then dynamic issues like access control can be also be handled.

Different types of metalinks can be defined. In one particularembodiment four different types of metalinks are defined which here aredenoted “self”, “local”, “absolute” and “application”. A metalink oftype “self” references the current application that has generated theXML data, metalink type denoted “local” references resources, forexample images, which are local to the application. The “ref” attributemust then contain the relative path, relative to the application, to theresource. The metalink type denoted “absolute” is a link to any publicor private portal WEB page, resource or application. The “ref” attributemust contain the complete URL to such a resource. Finally the metalinktype denoted “application” refers to an application known by the portaland which has been defined and given a name by the portal. The referenceattribute should in this case contain the name of the application asdefined by the portal. Metalinks of type “self” and “application” arealways processed through the presentation layer whereas the “local” and“absolute” types need not. It is also possible to use one metalink typerelating to both metalinks of “local” and “absolute” type.

It is of course also possible to define other types of metalinks. Thedenotations are also merely examples, any denotations may be used.

In the following the portal core, and specifically the presentationarrangement, or the presentation layer, will be more thoroughlydescribed, particularly with reference to FIG. 4. The service tier, cf.FIG. 2, in one advantageous implementation comprises three serviceclasses. The service class portal core service (pcoreservice) complieswith the specifications of the portal core and it is used to leveragethe portal core characteristics. In one implementation the services areimplemented using the J2EE IBM WEBSphere Environment (an applicationserver used to develop programmatic services involving logic, algorithmsetc.). Such services generally have three or four tier architecturesdeploying JSP (Java Server Pages) on the front end, Java servlets andEnterprise Java Beans (EJB) in the middle layer and various entities onthe back end. The second service class are the integrated portal coreservices (integrated pcore services) which leverage pcore presentationservices but which are not necessarily implemented in the portal coreJ2EE environment, e.g. an external e-mail system running on a non-portalcore environment but adapted to present itself through the portal corepresentation. The third service class pcore external services neithercomply with the portal core service development nor with thepresentation architectures but the services have to be triggered to orbrokered by the portal core.

In one implementation there are two types of service options availablewithin the service layer. One may consist of services provided byBroadvision (Corba; for creating optimized rule based and personalizedservices connected to commerce and retail), and optimized for contentdelivery by a matching engine operating on content, profile and businessrules. The other service type relates to programmatic services forexample requiring algorithms, logic etc. which are not easily built inan optimized content delivery system. If these services are of pcoreservice class, then they may be industrialized for IBM WEBSphere J2EEenvironment and if they are of integrated services class and running inan external service server, they are adapted to the portal corepresentation.

A service needs specifications including elements on the renderingfunctionality of the presentation layer as well as relating to theservice layer functionality, i.e. schemes and logic. The portal corepresentation architecture may, as referred to above, in one advantageousembodiment implement the J2EE architecture for the mechanisms ofcreating and employing services in specific elements or for definingservices. However, the invention is not limited to a portal structureusing J2EE and Broadvision; these are merely examples.

The presentation layer is conceptually split-up into two tiers, onerendering layer residing in the portal core itself and a service layeravailable to any service that wants to presents its content through theportal core presentation structure. The rendering layer in oneadvantageous implementation uses XML/XSLT technologies. Thereby it isalso ensured that information presented by services within the portalcan be displayed in a standardized way irrespectively of which is theend user station, i.e. irrespectively of which kind of end user stationthe end user uses when accessing the portal. Through the use of XML/XSLTa unified “look and feel” of content may be presented within thepresentation space.

If XML is used as a generic markup language, a service produces anoutput in the form of an XML document formatted using structureinformation from a pcore DTD. The XML output from the service is thenused to feed the presentation engine of the presentation arrangement.The presentation engine uses pcore SS and pcore grid informationassociated with the pcore DTD of the XML document supplied by theservice to generate the desired interface. Services which do not produceXML from a pcore DTD are particularly also able to present themselvesthrough the presentation services.

As referred to earlier the portal structure is advantageously able tohandle different devices such as WAP-phones and broadband devices suchas PCs. A portal core structure platform and the logic in it areparticularly totally separated from the presentation layerfunctionality, which makes it very easy to implement support for alldifferent types of clients, even voice and speech synthesizers. By usingfor example XML/XSL, it is very easy to implement support for instancefor a new type of WAP-display size. It is also possible to adapt therendering process to various WEB-devices, existing and future hand-helddevices, voice browsing and interactive TV.

In one particular implementation the WEB-interface is composed of squareelements also denoted bricks. A brick is a container of a service, apicture or an application. Using such bricks or containers, it ispossible to customize the portal. A brick is thus an application createdto be used inside the portal structure, which has a link to theapplication. The application has to provide display information to theportal when it wishes to render the brick. Advantageously a brick canappear in more than one format. The disposition of the bricks orcontainers represent a so called brick interface. In order to enableeasy navigation the WAP-interface will be structured in the same way. Inthe WEB-interface the user is presented with a list of available bricks.Each brick contains an application, service or a background picture thatcan be included in the users built WEB-site. A brick can also be apre-configured service from an external company or provider. ABrick-grid is a non-visual representation of a customized portal.Depending on device, the brick grid is represented in a way that is mostsuitable for the device in use. The grid can be designed in many ways aswell as the bricks may be presented and organized in different ways, forexample with tags. The brick grid is stored in a generic format and itis device/end user station independent.

Preferably the end user authenticates himself towards the portal with aone time login which will give the end user access to all thefunctionality within the portal. Any authentication towards connected orto external content or service providers is handled by the platformsecurity system. Advantageously each application or service within theportal can be personalized to fit the needs of the end user and eachapplication can be personalized for different devices. This isparticularly advantageous when an end user wants to limit the amount ofdata sent to another end user station with limited capacity to presentlarger amounts of data, e.g. a WAP-phone. It is possible to select oneapplication more than once and to give each of the different instancesits own personalization.

The inventive concept will be more thoroughly described with referenceto FIG. 5. FIG. 5 is an illustration similar to that of FIG. 3 butillustrating somewhat more in detail an application generating XML datawith possible metalinks and providing the XML data to the renderingengine 15 of the presentation layer 11 of the portal core 1 having senta request to the application 25. In the first translating means 16,which actually forms part of the rendering process (or comprises aseparate process within the rendering engine) metalinks are translatedto real addresses of the application/services/content referred to by therespective metalink. XML data with the real address is then furtherprocessed by the rendering means in a separate process 17 or within thecommon process constituting the first 16 and second 17 translating meansto render the XML data and output it in a format understandable to theend user station, i.e. translating it into the markup languageunderstood by the end user station. In FIG. 5 it is supposed that theend user station is. a WAP-phone 5. In that case, in thisimplementation, the XML data is translated to WML.

The procedure when an end user station, e.g. via a WEB-browser or aWAP-phone requests application data from a portal is described withreference to the flow diagram in FIG. 6. It is supposed that aWEB-browser/WAP-device requests application data from the portal bysending a request to the portal, 100. The request is thereupon handledin the presentation arrangement (layer) of the portal core and therequest is forwarded to the requested application, 101. The applicationthen uses/generates XML data (in this embodiment) with or withoutmetalinks depending on whether it wants to refer to other applicationsor services or not, 102.

Subsequently the application sends a response with the XML data andpossible metalinks and possibly also metainformation tags to thepresentation layer of the portal core, 103. An embodiment in which alsometainformation tags are introduced to the XML-data is more specificallyillustrated in FIG. 8, therefore this is not indicated in FIG. 6, butmerely briefly referred to. In the portal core it is examined whetherthe response contains any metalinks, 104. (If the concept ofmetainformation tags is implemented, it is here examined if anymetainformation tags are contained in the response. If yes, themetainformation is stored in the portal, e.g. in a portal sessioncreated for the requesting end user relating to the requestedservice/application, where it is stored for a given period of time, e.g.until the session has been idle for a preset time interval.) If theresponse contains metalinks, yes, the metalinks are translated by firsttranslating means in the rendering engine or the rendering means in thepresentation arrangement (layer) into real addresses, 105. Thereupon thetranslation of the XML data is performed by the second translating meansof the rendering engine, e.g. to HTML or WML, 106. In case there are nometalinks, cf. 104 above, step 105 is redundant and the XML data isdirectly translated into HTML or WML (for example). Subsequently theresult is output in HTML or WML to the requester depending on whichmarkup language that is used by the end user station, 107. It should beclear that, when referring to first and second translating means it isactually referred to processes within the presentation arrangement orspecifically within the rendering engine.

The inventive procedure will now be described somewhat more in detailwith reference to FIG. 7. When an end user accesses the portal byaccessing an application, the end user in one implementation clicks on alink containing parameters describing the application, 200.Alternatively the portal URL address can be typed in the browser or onthe WAP-device. The link has to contain a parameter describing whichapplication the user wants to access. As an example, if the user wantsto access an application denoted “bricks”, the user could type in theURL:

-   -   http://www.pcore.net?app=bricks

When the portal structure has received the request and read theapplication parameters, it looks for the information, e.g. inapplication managing means, which is needed to contact the application.This information includes the URL that is required for connection to theapplication, 210. The portal then accesses the application by the URLaddress, 220. The application, when having been accessed by the portalstructure, starts to run and produce XML. If the application wants toadd links back to itself or to some other application etc., itintroduces metalink tags into the XML data as discussed more thoroughlyabove, 230. (In one implementation may also metainformation tags beintroduced into the XML data by the application. Metainformation tagsmay also be introduced regardless of whether any metalink tags areintroduced.)

As an example, the application “bricks” as referred to above, might wantto link back to itself by producing the metalink:

-   -   <metalink type=“self” />

The portal will then replace this with: <metalink type=“self”base=“http://www.pcore.net”><   <param name=“app” value=“bricks” /></metalink>

Then the XML data, with or without one or more metalink tags, isreturned to the portal core, or more particularly to the presentationlayer. The portal core, i.e. the rendering means or the rendering engineof the presentation arrangement receives the application XML data andprocesses all metalinks (if any) and inserts a base argument with thecorrect address to the application, 240.

Depending on type of end user station an appropriate XSLT (XSLtransformation sheet) is used for the rendering of the XML data into aformat (other markup language) that the end user station can understand.The XML data is then rendered (translated) into the appropriatelanguage, 250, and finally it is sent back to the end user, 260. In therendering process all the metalink tags are translated to links in thetarget language.

In a particularly advantageous implementation a service or anapplication (although it is sometimes only referred to as an applicationin this document, it should be clear that also a service, or a contentcould be meant) may include or generate one or more metainformation tagsin the XML data. The DTD for the metainformation or metainfo, could be,if the param (parameter) is the same as the metalink:

-   -   <!ELEMENT metainfo (param*)>

For example a metainfo tag may look like: <metainfo>   <paramname=“externalsessionid” value=“4711” />   <param name=“userid”value=“jan” /> </metainfo>

All the parameters in a metainformation tag will then, by the renderingprocess, be added to all the metalink parameters, particularly of type“self” or “application” as referred to above.

All parameters that are common to all the links in the application willthen be defined in one place and they are advantageously stored bystoring means in or associated with the portal core. In that way thestored parameters (common to all the links of an application) can thenbe sent to the application when the same end user accesses theapplication subsequently (during the same session). The parameters arethus stored per end user and per application instance and differentapplication instances can thus have different global parameters. Anadvantage of such an implementation is that the parameter list andthereby the address (URLs) for applications that are sent to an end usercan be much shorter. This is particularly of importance if an end useraccesses the portal using a mobile end user station such as aWAP-device. Only the parameters that are different for different linkshave to be sent to the end user station. The concept of introducingmetainformation tags may also be implemented irrespectively of whetherthe concept of metalink tags is implemented.

For an implementation in which provision of metainformation tags isimplemented, a user accesses an application in the portal by clicking alink in e.g. a browser. As above, the link contains parameters to someapplication. In the portal the real addresses to the application arelooked up and the parameters are added. Subsequently the portal checksto see if there is any metainformation stored for the particularapplication instance and for the particular end user. If yes, the storedmetainformation parameters are also added to the address. The request isthen sent to the application (containing parameters to the applicationand metainformation parameters if there were any). The application thendelivers XML data back to the portal core. It contains, or may contain,metalinks and metainformation. In the portal the URL in the metalinks istranslated/replaced by the URL to the portal. The metainformation data(if any) are stored for possible subsequent accesses by the same enduser during the session. The application XML data is then rendered ortranslated, i.e. the rendering means processes the complete XML documentincluding possible metalinks, to produce an output format understandableby the end user station.

An example of a flow describing an embodiment implementing introductionof metainformation tags will be more thoroughly described with referenceto FIG. 8. The first two steps are substantially identical to the twofirst steps as described with reference to blocks 200 and 210 of FIG. 7.Moreover, in this implementation it is examined if the user has accessedthe same application before during same session, 211. If yes, it ischecked if there is any metainformation stored in the storing means forthat application and end user, 212. If yes, the stored metainformationis added to the request to the application, 213. The subsequent stepcorresponds to step 220 of FIG. 7 with the difference that alsometainformation has been added to the request. In the subsequent step,substantially corresponding to step 230 of FIG. 7, if there aremetainformation parameters, they are contained in the metalink tags(such parameters will be sent back to the application if the end userclicks the link at a later stage). If all or many of the links containthe same information, for example an external session id used by theapplication, this information could be added to all metalinks. But inorder to save space in the XML document, all these common parameters canbe removed from all metalinks and replaced by one metainformation tagcontaining all said parameters. This metainformation will be stored inthe portal session and sent back to the application the next time it isaccessed by the end user during the same session. This also reduces theURL length in the links since the data is stored in the portal insteadof being sent to the user, 231. Subsequently the step corresponding toblock 240 of FIG. 7 is performed, i.e. the portal receives the XML datawith possible metalinks and metainformation tags.

All metainformation data (if any), in the session is stored in thestoring means in or associated with the portal core such that it can besent back to the application the next time it is accessed. For eachapplication a namespace is created in the session where themetainformation is stored. The portal will also add a namespaceparameter to all metalinks, which then will be sent back to the user inthe links. On a subsequent access by the same end user to the sameapplication, the portal will use this namespace argument to do thelookup in the session. The session id is also added to the metalink as aparameter so that the portal can find the correct session the next time.After this transformations the metalink might look like: <metalinktype=“self” base=“http://www.pcore.net”>   <param name=“app”value=“bricks” />   <param name=“session_id” value=“s123” />   <paramname=“namespace” value=“nsll” /> </metalink>

For convenience all the params are added togheter with the base argumentinto an URL argument as in HTML, as will be described below.

Subsequently follow the steps corresponding to blocks 250, 260 of FIG.7.

In the rendering process all metalink tags are translated to links inthe target language and the above metalink could for example betranslated into (using HTML): <AHREF=“http://www.pcore.net?app=bricks&session_id=123& namespace=nsll>Click</A>

The above flow may e.g. be examplified as follows: If the link clickedto access the portal is a link generated via a metalink, it might looklike: http://www.pcore.net?app=bricks&session_id=s123&namespace=nsll&applicationparameter=Hello

The portal will then first lookup the application URL as above, and forbricks it might be:

-   -   http://applications.pcore-net/bricks

and all the other parameters in the request will be added, thusproviding:http://applications.pcore.net/bricks?app=bricks&session_id=s123&namespace=nsll&applicationparameter=Hello

Then a check is performed in the session to see if there is anymetainformation stored. If that is the case, all metainformationparameters are added and the result could then be:http://applications.pcore.net/bricks?app=bricks&session_id=s123?namespace=nsll&applicationparameter=Hello&external_session_id_(—) 123

It is an advantage of the invention that it provides for a genericframework for seamless navigation between applications inside theportal. The links between any applications can be written independentlyof the portal or location of the applications and independently also ofthe type of end user station.

If the concept of metainformation is implemented in addition thereto, itis very advantageous that the links and parameters that have to be sentto the end stations are considerably reduced since common parameters arestored in the portal.

The concept of using metainformation may also be implementedirrespectively of whether the concept of metalink tags is implemented.Then, however, it may be implemented with other links, e.g. XLink orlinks similar to metalinks.

It should be clear that the invention is not limited to the specificallyillustrated embodiments but that it can be varied in a number of wayswithin the scope of the appended claims.

1-32. (canceled)
 33. A portal for providing end user stations withaccess to services/applications, comprising: a portal core having anumber of service enabling means; a connectivity layer via which enduser station access is provided; a number of services/applications,wherein the services/applications are represented in a generic markuplanguage, the portal core using said generic markup language for storingat least application/service data information and for communication withsaid services/applications; and a presentation arrangement forcommunication with said applications/services and said end userstations, each service/application represented by generic data in thegeneric markup language optionally being provided with a number ofmetalink tags, such that each service/application is able to generategeneric link data in the generic markup language irrespectively of thelocation of the portal and of other applications, wherein thepresentation arrangement comprises first translating means for replacingsuch metalinks with real (public) addresses of theservices/applications, such that continuous navigation is enabled forend users irrespectively of the location of accessedservices/applications.
 34. A portal according to claim 33, wherein theportal core comprises rendering means comprising said first translatingmeans.
 35. A portal according to claim 34, wherein the presentationarrangement comprises said rendering means.
 36. A portal according toclaim 34, wherein the rendering means comprises second translating meansfor translating/rendering service/application data in the generic markuplanguage into a markup language used by the end user station.
 37. Aportal according to claim 33, wherein the portal core further comprisessession handling means for user session management.
 38. A portalaccording to claim 37, wherein said session handling means are separatefrom, but in communication with, said rendering means.
 39. A portalaccording to claim 33, wherein a number of types of metalinks aredefined depending on the location of the linked service/application inrelation to the service/application accessed by the portal core.
 40. Aportal according to claim 39, wherein a first type of metalink (“self”)is defined which refers to the service/application that itself hasgenerated the data, as represented in the generic markup language.
 41. Aportal according to claim 39, wherein a second type of metalink(“local”) is defined which refers to resources which are local to thecurrent service/application and in that it includes information aboutthe path to the resource in relation to the current service/application.42. A portal structure according to claim 39, wherein a third type ofmetalink (“absolute”) is defined which comprises a link to any public orprivate portal, web-page, resource, application or content and in thatit contains a complete URL-address to such portal, resource etc.
 43. Aportal according to claim 39, wherein a fourth type of metalink(“application”) is defined which refers to an application which isdefined in the portal under a given name and in that the metalinkcontains information about said name.
 44. A portal according to claim33, wherein data representing services/applications expressed in thegeneric markup language and metalinks are defined in a Document TypeDefinition Language with an URL-attribute.
 45. A portal according toclaim 33, wherein said portal supports access by mobile end userstations.
 46. A portal according to claim 45, wherein said portalsupports access by fixed end user stations, e.g. PC:s, wherein fixed enduser stations use a markup language different from the markuplanguage(s) used by mobile end user stations.
 47. A portal according toclaim 33, wherein a service/application optionally is provided with anumber of metainformation tags and in that the rendering means adds theparameters of said metainformation tag(s) to all metalink parameters atleast for some type(s) of metalinks.
 48. A portal according to claim 47,wherein an application/service comprises a number of links to otherapplications/services, that metainformation tags optionally can be addedto “self” or “application” type metalinks and in that all parameterscommon to all the links of an application are stored in the portal coreper end user and per application instance.
 49. A portal according toclaim 45, wherein said portal supports access to services/applicationsby mobile end user stations, e.g. WAP-devices over a mobilecommunications network with access nodes in the connecting layer andfixed stations WEB-devices, e.g. broadband devices such as PC:s.
 50. Aportal according to claim 33, wherein the generic markup language isXML.
 51. A portal according to claim 50, wherein the XML data and themetalinks are defined in a Document Type Definition language (DTD) andin that a metalink tag in XML comprises information about metalink type,addressing attributes containing service/application locationinformation depending on metalink type and a number of parameters.
 52. Aportal according to claim 33, wherein the second translating meanstranslates XML data by performing a transformation (XSL) to an outputformat, i.e. a markup language appropriate for an accessing end userstation, e.g. HTML for a fixed end user station or WML for a mobile enduser station.
 53. A portal for providing end user stations with accessto services/applications comprising: a portal core; a number of serviceenabling means; a connecting and data bearer layer via which end useraccess is provided; and a number of services/applications, wherein theportal core is XML-based using XML as a markup language for storing dataas XML-data and for communication with services/applications, andwherein the portal core comprises means handling presentation on enduser stations, that the services/applications generate XML-data, aservice/application generating XML-data optionally being provided withmetalink tag(s) for referring to otherapplication(s)/service(s)/content, such that each service/application isable to generate XML link data independently of which is the location ofthe portal core and of other services/applications, and wherein theportal core comprises first translating means for replacing metalinkswith real addresses of services/applications, such that continuousnavigation is provided for end users independently of the location ofaccessed services/applications.
 54. A portal according to claim 53,wherein it supports end user access by mobile as well as fixed end userstations, e.g. WAP-devices and broadband devices such as PC:s,interactive TV etc.
 55. A portal for providing end user access toservices/applications comprising: a functional services/applicationslayer; a user access layer; and an intermediate communication layer forcommunication with services/applications and end user access means(stations), wherein the intermediate communication layer comprises apresentation arrangement with rendering means and session handling meansreceiving requests for services/applications by end user stations,forwarding such requests to the requested service/application, and forreceiving XML-data information representing requestedservices/applications, that the services/applications may be providedwith metalink tag(s) for referring to otherapplications/services/contents, said rendering means comprisingtranslating means for replacing metalinks with corresponding realaddress information relating to services/applications and means fortranslating such XML-data information to a format usable by therequesting end user station.
 56. A method for providing an end userstation with access to services/applications via a portal comprising aportal core, a plurality of services/applications and end userconnectivity means, comprising the steps of: providing anapplication/service in a generic markup language with a number ofmetalink tags for referring to other application(s)/service(s)/contentand/or with a number of metainformation tags; receiving in the portalcore a request for a service/application from an end user station in theend user language format; forwarding the request to the requestedservice/application; returning data relating to the requestedservice/application as represented by the generic markup language to theportal core with possible metalink tags and/or metainformation tags;translating the metalinks defined by the tags to real addresses of thelinks in the portal core and/or storing the metainformation of themetainformation tags into a portal session for the end user relating tothe requested service/application; and providing the service/applicationto the end user station in a format appropriate for the end userstation.
 57. A method according to claim 56, wherein the portal corecomprises rendering means, said rendering means performing the steps of:detecting if data of a service/application delivered in the genericmarkup language contains any metalinks; and if yes, processing saidmetalink(s) and replacing it with the real address of theservice/application referred to.
 58. A method according to claim 56,further comprising the step of providing services/applications withmetalinks of given types depending on where the content of aservice/application, to which there should be a link, is located.
 59. Amethod according to claim 58, further comprising the steps of: providingan application/service with a metalink tag referring to the applicationitself for content provided by the application/service itself; providinga service/application with a metalink tag referring to local content forcontent provided local to the service/application, which metalinkcontains a reference to the path to the content relative to theservice/application; providing a service/application with a metalink tagreferring to any portal, content etc which comprises an attribute withthe complete URL address of said portal, content etc.; and providing aservice/application with a metalink tag referring to anotherservice/application if said other application/service is known and givena name by the portal, including a reference attribute containing thegiven name.
 60. A method according to claim 56, further comprising thesteps of: providing a service/an application with a metainformation tagcomprising a number of parameters; adding the metainformation parametersto the metalink parameters; storing the metalink parameters and themetainformation parameters common to all the links of theservice/application parameters in common in storing means in orassociated with the portal core per user and per service/applicationinstance; and sending the parameters that are different for differentlinks to the requesting user terminal.
 61. A method according to claims56, further comprising the step of translating the service/applicationdata as expressed in the generic markup language into the/a markuplanguage used by the requesting terminal station.
 62. A method accordingto claim 56, wherein the portal is mobile and supports access by mobileend user stations, e.g. WAP-devices as well as fixed end user stations,e.g. PC:s.
 63. A method according to claim 56, wherein the genericmarkup language is XML and in that the rendering means supportstranslation into e.g. HTML as well as WML.
 64. A method of accessing aservice/application from an end user station comprising the steps of:accessing a portal by selecting a link with parameters to a desiredservice/application; performing a look-up to find the real address ofthe service/application in the portal; adding the link parameters to thereal address; examining if any metainformation parameters are storedrelating to the requested service/application instance for therequesting end user, if yes, adding the stored metainformationparameters to the real address with added link parameters; sending therequest containing at least link parameters to the service/application;delivering service/application data expressed in a generic markuplanguage (XML) including metalink tags and/or metainformation tags tothe portal core; replacing metalink address information by real addressinformation and/or; storing received metainformation in storing meansassociated with the portal core; and processing the service/applicationdata in a generic markup language and converting it to the format usedby the end user station.